## Context
@products/feature_flags/backend/user_blast_radius.py#L151-173
@products/feature_flags/backend/user_blast_radius.py#L196

<issue_description>
Each condition request scans 30 days of events and calculates `uniq(person_id)`. The frontend sends one request for every condition. This repeats the same team-wide query concurrently and can add significant ClickHouse load for active projects.
</issue_description>

<issue_validation>
- **Checked:** the new helper and its two call sites in the diff, the API action that serves each request, the frontend triggers that fan out those requests, what the replaced query cost on `master`, whether any layer dedupes or caches the result, and whether the repo already has a short-lived cache helper.
- **Found:** the helper carries no caching. `recently_active_persons_count` builds and runs `SELECT uniq(person_id) FROM events WHERE timestamp >= {cutoff}` on every call (`products/feature_flags/backend/user_blast_radius.py:151-171`), and it is called on both blast-radius paths (`:182`, `:196`). The endpoint runs one `get_user_blast_radius` per POST (`products/feature_flags/backend/api/feature_flag.py:4140-4149`), so each request re-runs the team-wide scan.
- **Found:** the request fan-out is one per condition set. `calculateBlastRadius` loops over `values.filters.groups` and dispatches `calculateBlastRadiusForCondition` for each (`frontend/src/scenes/feature-flags/featureFlagReleaseConditionsLogic.ts:828-836`), and it fires on mount (`:1206-1210`), on filter load (`:692-695`), and on aggregation change (`:781`). Editing a condition adds another call after a 1 second breakpoint (`:741-746`). Opening a flag with several condition sets therefore issues that many concurrent identical team-wide queries.
- **Found:** nothing absorbs the repeats. `execute_hogql_query` is a thin wrapper over `HogQLQueryExecutor(...).execute()` (`posthog/hogql/query.py:794-795`) with no result cache, and the helper is a plain module function, so there is no per-team or per-process memoization.
- **Found:** the diff makes the per-request query much heavier than what it replaced. `master` read the person table once per request via `team.persons_seen_so_far` (`posthog/models/team/team.py:872-888`), whose `@cached_property` only spans a single request. The replacement reads 30 days of the team's events plus a `person_distinct_id_overrides` subquery join — the snapshots regenerated in this PR show that exact shape with `max_execution_time=60`. For a high-volume project, 30 days of events is orders of magnitude more rows than the person table, so the fan-out that already existed now multiplies a far larger query.
- **Found:** the new query runs on the default workload. The neighboring group path deliberately sends its heavy count to `Workload.OFFLINE` because "groups queries can be massive" (`products/feature_flags/backend/user_blast_radius.py:251-257`), while the new events scan gets no such treatment and lands on the online cluster that serves interactive traffic.
- **Impact:** confirmed duplicated load on an interactive path: opening the release conditions panel of a flag with N condition sets triggers N identical 30-day `uniq(person_id)` scans, concurrently, per viewer, and again after each condition edit. The 60 second execution ceiling in the generated query also means the panel can fail outright for the largest teams, which the frontend renders as the blast-radius error state.
- **Impact:** the remedy is cheap and has in-repo precedent — `cache_for` in `posthog/cache_utils.py:67` is already used for exactly this kind of team-level count (`posthog/models/team/util.py:379`), so a short TTL keyed by team removes the duplication without changing the filtered per-condition query.
</issue_validation>

## Task
Investigate the issue and solve it

<potential_solution>
Cache the count by team for a short period, such as five minutes. Alternatively, return one shared total through a batch request. Keep the filtered count separate because it changes by condition.
</potential_solution>

## Context
@products/feature_flags/backend/user_blast_radius.py#L195-228

<issue_description>
The `IN` subquery selects every historical person that matches the filter. ClickHouse must build this set before it applies the recent event window. Broad filters can materialize millions of person IDs and cause high memory use or query timeouts. Anonymous churn makes this risk larger.
</issue_description>

<issue_validation>
- **Checked:** the generated ClickHouse SQL the PR itself regenerated in `products/feature_flags/backend/api/test/__snapshots__/test_feature_flag.ambr`, the pre-PR query shapes, the query settings applied, the workload each path uses, and how often the endpoint fires from the flag editor.
- **Found:** the snapshot confirms the `IN` right-hand side carries no time bound. `TestBlastRadius.test_user_blast_radius.1` shows `in(if(not(empty(events__override.distinct_id)), events__override.person_id, events.person_id), (SELECT persons.id ... FROM person WHERE equals(person.team_id, ...) ... GROUP BY person.id HAVING ...))`. The subquery aggregates the team's whole `person` table with `argMax` over all versions and applies only the property filter. The outer `greaterOrEquals(events.timestamp, ...)` cannot prune it, because ClickHouse evaluates an `IN` subquery into a set independently of the outer `WHERE`.
- **Found:** the new query adds two more unbounded scans around that set build. It reads `events` for the team from the cutoff, and it `LEFT OUTER JOIN`s a full `person_distinct_id_overrides` aggregation for the team (`GROUP BY person_distinct_id_overrides.distinct_id`, no time bound), because HogQL resolves `person_id` on `events` through the overrides table.
- **Found:** all of that runs inside one statement under `max_execution_time=60` with `max_bytes_before_external_group_by=0`, so the person `GROUP BY` cannot spill to disk. The snapshot lists both settings.
- **Found:** it runs on the default online workload. `recently_active_matched_persons_count` calls `execute_hogql_query(query=query, team=team)` with no `workload` argument, while the group path deliberately passes `workload=Workload.OFFLINE` with the comment "groups queries can be massive" (`products/feature_flags/backend/user_blast_radius.py:251-256`). The codebase already treats this class of query as too heavy for the online cluster.
- **Found:** the endpoint is interactive, not a batch job. `calculateBlastRadius` fans out one POST per condition set (`frontend/src/scenes/feature-flags/featureFlagReleaseConditionsLogic.ts:828-836`), and each POST issues two ClickHouse queries because `_get_person_blast_radius` always calls `recently_active_persons_count` before the matched query. Property edits are debounced by `await breakpoint(1000)` at line 740, but opening the editor is not.
- **Found:** the person-side scan is pre-existing, so the regression is additive rather than new. The old snapshot for the same test ran that identical `persons` subquery as the entire query with `count(DISTINCT persons.id)`. The PR wraps that same work in a 30-day events scan plus the overrides join, under the same 60s cap.
- **Found:** the suggested alternative is implementable in this codebase. HogQL exposes person properties through the `events` table, so `property_to_expr` in event scope can push the filter into the events scan instead of a separate person aggregation, which is how insight queries filter events by person property.
- **Impact:** for a team with a large person table and a broad person-property filter, the numerator query must aggregate every historical matching person into a set, join the full overrides table, and scan 30 days of events, all within 60 seconds on the online cluster, once per condition set each time someone opens a flag's release conditions. On timeout the frontend degrades visibly rather than showing wrong data — `setBlastRadiusError` drives the "Couldn't estimate how many … match." state with a Retry button (`frontend/src/scenes/feature-flags/FeatureFlagReleaseConditions.tsx:460-482`) — so the confirmed consequence is lost estimates and wasted online-cluster capacity, not corrupt results.
</issue_validation>

## Task
Investigate the issue and solve it

<potential_solution>
Restrict the person side to active IDs before ClickHouse materializes the match set. Prefer one query that scans recent events and joins the related person data. Confirm the query plan with a broad filter and a large historical person population.
</potential_solution>